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Commissioner for Patents 
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Alexandria, VA 22313-1450 

Sir: 

Reconsideration of the above-identified application and the rejections set forth in 
the Office Action dated November 7, 2002 in light of the following remarks is respectfully 
requested. The rejections and issues raised by the Office Action are addressed in the same order 
presented in the Office Action. 

I, The 35 USC^ 101 Rejection 

Claim 33 has been rejected under 35 U.S.C. § 101 as claiming the same invention 
as that of Claim 1 of U.S. Patent No. 5,758,072. While the Office Action states that the 
"rejection is based, in part , on applicants' admissions and remarks contained in the 'Request For 
Interference Under 37 CFR § 1.607' filed on September 18; 1997," the only stated basis for this 
rejection is the alleged admissions in the September 18, 1997 paper. 
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Applicants respectfully submit that any reliance on Iheir alleged admission is 
misplaced. In their response filed on March 1, 1999, Applicants withdrew their reliance on 
Claim 10 of application Serial No. 08/740,043 (which ultimately issued as Claim 1 of the '072 
patent) as the basis for satisfying the requirements of 35 U.S.C. §1 35(b). As a result, whatever 
admission might exist with respect to that claim, it is irrelevant to the present proceedings 
because Claim 1 of the '072 patent no longer serves as the predicate for Applicants' interference 
request. 

Instead, Applicants have, since March 1, 1999, relied on Claim 1 of application 
Serial No. 08/158,026)is the basis for satisfying section 135(b). This claim has not issued in a 




patent and thus cannot form the basis for a statutory double patenting rejection. 

Accordingly, the statutory double patenting rejection of Applicant's Claim 33 
under 35 U.S.C. § 101 should be withdrawn because the stated predicate for that rejection is not 
viable. 

II. The Obviouness-Type Double Patenting Rejection Of Claims 
34-72 Based On Claim 1 Of U.S. Paten t No. 5,758,072 

Claims 34-72 have been rejected under the judicially created doctrine of 

obviousness type double patenting as being unpatentable over Claim 1 of the '072 patent. This 

rejection is also based on Applicant's alleged admission, since withdrawn, with respect to Claim 

10 of Application Serial No. 08/158,026, which issued as Claim 1 of the '072 patent. Therefore, 

for the reasons set forth herein, no basis exists for this rejection. However, if Applicants remarks 

herein are not deemed sufficiently persuasive to overcome the instant rejection. Applicants 

attorneys will file a terminal disclaimer to obviate the rejection. 
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III. The Obviousness-Type Double Patenting Rejection of 
Claims 33-34, 43-46, 47, 57-60, 62, 64-66, 67 and 70-72 
Based on Claims 1-6 of U.S. Patent N o. 6.182,123 

Claims 33-34, 43-47, 57-60, 62, 64-67 and 70-72 have been rejected under the 
judicially created doctrine of obviousness-type double patenting as being unpatentable over 
Claims 1-6 of U.S. Patent No. 6,182,123. Applicants' attorneys will file a terminal disclaimer to 
obviate this rejection. 

IV. The 35 USC SI 12 Rejections 

Claims 35-36, 48-49 and 62-72 have been rejected under 35 U.S.C. § 112, first 
paragraph, as lacking written description in the specification supporting (1) the steps of 
automatically connecting the remote computer to the main computer after the selecting step, and 
automatically disconnecting after the variable data is received (Claim 35-36, 48-49 and 68-69); 
and (2) the recitation of an electronic catalog system (Claims 62-72). Applicants respectfully 
request reconsideration of these rejections. 

Contrary to the Office Action's contention, the recitation in claims 35-36, 48-49 
and 68-69 of automatically connecting the remote computer to the main computer after the 
selectmg step, and automatically disconnecting after the variable data is received, is supported by 
the specification of Applicants' priority application Serial No. 08/158,026. For example, the 
^026 specification contains the following explanation of those automatic operations: 

The first program, shown in Display field 270, 271, is called an 
initializer and is invoked unconditionally by TBOL interpreter 438 
concurrently with display of presentation data for the partition. In 
this application, the function of the initializer is represented by the 
following pseudo-code: 

1. Move default values to input and display 
fields; 



- J 



76N92 vl 



PATENT 



AITORNF.Y DOCKET NO. 1963-4727 



2. "SEND" a transaction to the apple 
application that is resident on interactive 
system 10; 

3. "RECEIVE" ihe result from interactive 
system 10; i.e. the current price of an apple; 

4. Move the price of an apple to PEV 271 so 
that it will be displayed; 

5. Position the cursor on the input field; and 

6. Terminate execution of this logic. 

Specification, P. 149, Une 28- P. 150, line 5 (emphasis added). Applicants' specification further 
discloses that data which is not available at the remote computer will be retrieved from the main 
computer (P. 150, lines 34-36). No action is required by the user once an application is selected 
which requires data not available at the remote computer. The request will be sent to the main 
computer automatically. 

In any event, the steps of automatically connecting and disconnecting are inherent 
in a distributed computing environment of the type disclosed by Applicants wherein data for use 
in applications at the remote computer is retneved fi-om the network delivery system (i.e., main 
computer) when such data is not stored at the remote computer. After the remote computer 
software determines that needed data is not available at the remote computer, it has no choice but 
to retrieve the data from the main computer; no action is required on the part of the user once an 
application is selected which requires data not stored at the remote computer. This is a 
fundamental aspect of Applicants' invention. 

Applicants' specification also supports the electronic catalog system of Claims 
62-72. Applicants disclose a remote computer with memory for storing programs having 
revision indicia in the form of a network that features a plurality of remote computers for 
displaying infonnation and providing transactional services to users. Specification p.7, Imes 7- 
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14. A specific example of the accessing of product infonnalion and completing a transaction 
involving the product is provided by Applicants as the example of a user at the remote computer 
purchasing an apple through the network. At p, 137, hues 13-19, the price of an apple is 
described as data transmitted from the network (i.e., variable data) because it changes so 
frequently that the most current value always must be obtained from the network and there is 
thus no point in storing it locally. At p. 148, line 26- p. 153, line 10, the entire procedure by 
which the user interacts with the remote computer and the network to purchase apples is detailed. 
Again, at p. 149, line 36, the price of an apple is obtained from the network delivery system (or 
main computer) after being selected at the remote computer. The presentation data etc. related to 
the interactive apple purchase (i.e., constant data) is stored remotely because it does not change 
frequently- The constant presentation data etc. related to the purchase of apples is clearly shown 
in Applicants' Fig. 3b, with blank spaces for the variable price data which is ultimately 
transmitted from the network. Thus, Applicants disclose, inter alia, integrating constant data 
related to an apple purchase stored at a remote computer with variable data related to, e.g., the 
price of an apple obtained from the network delivery system. 

V. The Purported Claim Rejections Under 35 USC ^102/103 

At pages 12-13, the Office Action has raised an earlier rejection based on Johnson 
et al. that was made in Applicants' priority application Serial No. 08/158,026. However, the 
Office Action explicitly states that "no art rejection of claim 33 based upon Johnson et al. is 
presented." 

While no response appears to be required. Applicants respectfully reiterate, as a 
precaution, their traversal of the earlier rejection based on Johnson et al. Thus, as previously 
mentioned, Johnson et al. do not teach or suggest classification of data into types depending on 
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the frequency of change of the data, i.e., constant and variable data, ascribing storage control 
attributes to the data depending on its frequency of change and updating constant data at the 
remote computer if it is determined to be stale after comparing the revision status of analogous 
data stored on the main computer. Johnson et al. merely describe file sharing between nodes in a 
distributed computing environment and say nothing about the constant/variable dichotomy with 
respect to product information displayed on a remote computer in a network as appreciated, 
disclosed and claimed by Applicants. 

VL The Inquiry Under 35 USC $102 

The Office Action asserts that "an issue as to patentability of the claimed subject 
matter because of public use or on sale activity has been raised by the applicant in this 
application." According to the Office Action, Applicants stated in introductory remarks to a 
paper filed on September 18, 1997 herein (page 2) that Applicants were entitled to an effective 
filing date of July 28, 1989 and the Office Action drew the inference that by these introductory 
remarks Applicants had conceded the priority of two earlier applications. 

To be clear. Applicants did not concede anything with respect to the priority of 
(^theii^ filed on July 15,J.9.88^ andJ4a_rch 23, 1989, as inferred incoiTCCtly by the^ 

Office Action. Applicants have steadfastly maintained their claim to a priority date for the 
subject matter of claims 33^72 of at least as early as July 28, 1989.^Indeed, in the same 
September 18, 1997 paper cited by the Examiner, under the heading "Effective Filing Date", 
Applicants specifically stated that "Applicants are entitled to a priority date of at least July 28; 
1989..." (page 16). The Office Action's characterization of Applicants' attorney's statement (at 
page 2 of the paper) as a concession was erroneous. Applicant's attorney's statement was made 
in the context of merely predating the filing date of Hill's U.S. Patent No. 5,528,490; it had 
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nothing to do with the pubhc use or on-sale inquiiy raised for the first time by the present Office 
Action. Although it is believed unnecessary to address or overcome the points made in the 
Office Action as to Applicants' priority dates, the disclosure of Applicants' March 23, 1989 
application clearly supports copied Claims 33-72. 

In order to eliminate any possible confusion, and for purposes of the instantly- 
claimed subject matter. Applicants now claim priority to at least as early as March 23, 1989 but ^ 

J 

Applicants do not concede priority to the July 15. 1988 filing date. For purposes of this-' 
Response, the issues of public use and on-sale need to be addressed only with regard to the 
March 23, 1989 and July 28, 1989 filing dates, without conceding pnority of the original July 15, 
1988 filing date. As demonstrated below, the subject matter claimed in Claims 33-72 was not in 
public use or on sale prior to March 23, 1988 or July 28, 1988, the critical dates corresponding to 
the March 23, 1989 and July 28, 1989 filing dates, respectively. 

A prior art disclosure statement under 37 C.F.R. §1.197 was filed on March 4, 
1991 in Applicants' great-great-grandparent application Serial No. 07/388,156 which included a 
disclosure of use information and an explanation as to why that use information is not 
anticipatory under 35 U.S.C. §102(b). The November 7, 2002 Office Action has required 
Applicants to provide additional information regarding the subject matter of the disclosure 
statement. An investigation has been undertaken to address this requirement for additional 
information, the results of which are summarized below. The undersigned attorney for 
Applicants makes the following statement on behalf of Applicants in response to subparagraphs 
(a) - (k) of paragraph 17 of the November 7, 2002 Office Action. 
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a. Basis of Statement 

The statement herein is based on contemporaneous documentary evidence which 
is identified hereafter, the Declarations of Theodore Papes and Frederick S. Larson, submitted 
herewith, and the related investigation performed by or on behalf of the undersigned attorney for 
Applicants and information provided to the undersigned attorney for Applicants from the related 
investigation. 

b. Relationship Between Claims 
And Implementation 

As originally conceived, the Prodigy® Service, to which this invention relates, 
called for a revolutionary new approach in distributed data processing. Indeed, it led to the first 
practical implementation of the Internet as we know it today. Thus the evidence submitted 
herein must be assessed relative to what was known prior to development of the modem Internet, 
during which time Prodigy was being developed. Because of its pioneering nature, almost two 
years was required to test and implement the Prodigy Service. 

In formulating the framework for the Prodigy Service, Applicants' believed that 
to be commercially viable, the service would have to handle user populations in the millions 
dispersed over the entire country and to achieve quick response to requests for information and 
execution of transactions and do so at low cost. To achieve quick response times while 
maintaining viable pncing. Applicants believed it necessary to design the service architecture 
to speed system operation and hold equipment capital and operating cost low. Accordingly, 
Applicants believed the "dumb" terminal approach commonly used in conventional 



Reference to Applicants, Prodigy or Trintex should be unde.stood to refer to Applicants and/or their assignees. 
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distributed computing systems at the time, with its rehance on host computer size and 
complexity, would not be suitable. 

Instead, Applicants proposed to structure the Prodigy Service so that a user could 
employ a personal computer (PC) to access the system. This would permit use of the computing 
power of the user's own PC, thereby reducing demand on network resources. Further, to 
configure the service so that it could be handled by a user's PC, it was proposed that applications 
offered on the service be partitioned; i.e., structured as separable units of data and program code 
capable of being processed by the PC. Also, Applicants recognized that if the partitioned 
application units were made up of program code and data; i.e., "objects," the objects could be 
distributed throughout the system so that application display time could be minimized as a 
function of the storage capacity of the PC. Applicants believed that by composing the 
application to be executed at the PC from objects stored at the PC, the applications could be 
presented quickly and with minimal reliance on service resources. 

However, to accommodate this intended role for the PC ("reception system"), the 
service software, i.e., software for the host, cache/concentrator system (collectively the "network 
delivery system") and reception system, together with the other support facilities - and the 
software for the various applications to be run on the service, had to be originally designed and 
created. Since these software designs would be new. Applicants naturally anticipated a 
substantial test and development period for the service software. 

The inventors were not sure prior to no earlier than August of 1988, when the 
reception system software was released for reproduction in anticipation of retail launch, thaf their 
complex invention would work as intended in a large network with many thousands of disparate 
users. In accordance with established principles of law regarding experimental use, where an 
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invention is complex and the inventor is not sure that it will work for its mlended purpose, the 
experimental use exception applies and a period of experimentation is reasonable to prove that 
the invention will work for its intended purpose. During that interval, theonej^ESCiod-of-lhe 
statute will not b egin to run. Pfaffv. Wells Electronics. Inc. , 525 U.S. 55, 64 (1998). 

Applying this principle to Claims 33-72 of the present application, the invention 
is an integral part of a very large, complex, interrelated network delivery system and PC 
workstations. There was no certainty by the inventors that the invention would work in its 
intended setting where many thousands of users across the country would be simultaneously 
using the system -- and ultimately millions of users. The invention needed a long and graduated 
period of testing by a large number of users across a large geographic area to confirm that it 
would work for its intended purpose. Importantly, the present invention is quite different and 
significantly more complex than the invention in Pfaffv Wells. 

Whether the public has access to the invention during the experimental test period 
is not dispositive with regard to the issue of public use. The rationale of the seminal Supreme 
Court road pavement case is illustrative: 

Nicholson wished to experiment on his pavement. He 
believed it to be a good thing, but he was not sure; and the 
only mode in which he could test it was to place a specimen 
of it in a public roadway.... The public had the incidental 
use of the pavement, it is true; but was the invention in 
public use, within the meaning of the statute? We think 
not. 

City of Elizabeth v. American Nicholson Pavement Co. , 97 U.S. 126, 136 (1877); seealsoEZ 
nock. Inc. V. Schafer Systems, Inc. , 276 F.3d 1347, 1352 (Fed. Cir. 2002) ("[A]n inventor who 
seeks to perfect his discovery may conduct extensive testing without losing his right to obtain a 
patent for his invention -- even if such testing occurs in the public eye.") Moreover, 
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"[c]ommercial purpose underlies virtually every contact between inventor and potential 
customer. When testing an invention entails customer contact, that does not convert an 
otherwise experimental purpose into a public use." Allied Colloids, hic. v. American Cyanamid 
Ca, 64 F.3d 1570, 1575 (Fed, Cir. 1995). 

The circumstances of the instant case are particularly analogous to those of City 
of Elizabeth , i.e., the only way to test the Prodigy System was to expand it to enough users to 
determine whether the system would work as intended under high-demand conditions. 

The test and development period for Applicants' invention extended over_almost 
two years and progressed through three phases. Throughout the three phases, efforts were 
undertaken to develop and test all components of the service hardware and software i.e., network 
delivery system, reception system, etc. 

c. All Of The Material Limitations Of Claim 33 
Were Described In Priority Applications 
Filed March 23. 1989 And July 28. 1989 

Claims 33-72 are entitled to priority to applications filed July 28, 1989 and March 
23, 1989 and the claimed subject matter was not in public use prior to one year before either 
date. 

The second continuation-in-part application ("CIP") was filed July 28, 1989, more 
than one year after a demonstration of a Prodigy prototype was conducted at the West Coast 
Computer Faire (hereafter "Computer Faire") in San Francisco, California during the week of 
;^pril 7, 1988. As discussed below, the members of the public attending the Faire were told that 
the Prodigy service was not available then and was not being offered for sale. The puq^ose of 
the demonstration at the Faire was experimental in nature -- i.e., to gather infonnation as to the 
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desirability and suitability of such a service, A further purpose for the demonstration was to 
expand the test user base so that more realistic testing of the system under actual anticipated 
conditions could be performed. 

Moreover, the difference between the second CEP's disclosure and that of the first 
CEP (filed March 23, 1989) is not needed to support Claim 33 of the instant application. Claim 
33 is directed to a method for distributing data in a network by including storage control 
parameters that establish the retention policy for that data at a local computer. The second CIP, 
filed July 28, 1989, added details of storage candidacy features, including fields in the message 
header for version ID, storage candidacy, classes of instability, and least recently used ("LRU") 
status. These attributes were broadly described in the first CIP and thus no features of Claim 33 
lack support in the first CIP application filed March 23, 1989. 

Further, the Prodigy Service demonstrated at the Computer Faire did not reveal 
the limitations of claims 33-72. At least the two claim limitations of (1) associating storage 
control parameters with the data to be stored, the control parameters dictating predetermined 
eligibility of the data for storage at the data stores, and (2) retaining data at the stores based on at 
least the eligibility for storage dictated by the respective storage control parameters could not 
have been revealed. Thus, there could have been no public disclosure of the claimed invention. 

Accordingly, the demonstration of the Prodigy Service at the Computer Faire 
more than one year before the filing date of the second CIP does not affect the patentability of 
the claims of the instant application. Also, the demonstration at the Computer Faire was less 
than one year prior to the first CIP filed March 23, 1989. Following is a detailed discussion of 
the testing of Applicants' invention from late 1987 through late 1988 to determine whether the 
invention would work for its intended purpose. 
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d. Stages of Experimental Testing 



A chronology of events pertinent to the disclosed use information and in response 



to the November 7, 2002 Office Action is summarized as follows: 



1. a first phase of Prodigy development and testing started in 
January 1987 and ended in September 1987, 

2. a second phase of Prodigy development and testing started 
October 1987 and ended March 1988, 

3. a demonstration of a Prodigy experimental prototype was 
conducted at the West Coast Computer Faire in San 
Francisco, California during April 7-10, 1988, 

4. a demonstration of a Prodigy experimental prototype was 
conducted at a Comdex convention in Atlanta, Georgia 
during early May 1988, 

5. the original parent application Serial No. 219,931 was filed 
on July 15, 1988, 

6. a third phase of Prodigy development and testing continued 
from March 1988 and ended on August 5, 1988 with the 
formal release of the reception system software from 
development to diskette reproduction so that public retail 
sale could commence in September 1988, 

1. a first continuation-in-part application Serial No. 
07/328,790 was filed March 23, 1989, less than one year 
after the reception system software was released for 
reproduction for retail sale to the public, 

8, a second continuation-in-part application Serial No. 
07/388,156 was filed July 28, 1989, also less than one year 
after the reception system software was released for 
reproduction for retail sale to the public. 

Throughout the three phases of the test and development period, Prodigy sought 
to determine whether the reception system was suitable for its intended purpose. Since the 
primary requirement for the reception system was to enable very large user populations to 
manipulate the partitioned applicaUons available on the service, the objective from the first 
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through the third phase of testing was two-fold: (1) to determine whether the reception system 
would be capable of automatically staging, i.e., storing constant data on a user's PC between 
sessions, and processing partitioned applications at all, including updating constant data, 
retrieving variable data f^om the network and integrating the two types of data together to create 
a display^; and (2) whether the capability to maintain current constant data on the user's PC, 
retrieve variable data on an as-needed basis and integrate constant and variable data to create a 
display would be sustained as user levels were progressively increased toward the levels 
anticipated for the intended environment and the distributed network became more and 
more geographically dispersed, i.e., as the network system became more and more 
taxed. 

Once Applicants recognized it was essential to expand the user population to 
assess whether the reception system would perform in its intended enviromnent. Applicants also 
recognized that at least a portion of the experimental testing would have to involve users who 
were members of the general public. Also, it was necessary to establish that reliable 
communication could be maintained for the required session lengths, which meant expanding to 
large numbers of users. 

The design of the reception system and other elements of the Prodigy Ser\'ice 
network required development of new and original software. The Service also required the 
multiple software elements to be coordinated and harmonized for cooperative operation within 
the Service network. New software and software combinations are inherently unpredictable in 
their initial stages of development. It is difficult, if not impossible, to know for sure how such 



' The response herein is directed to the issue of public use and/or on sale as raised by the November 7, 2002 Office 
Action, i.e., with respect to the currently claimed invention (copied claims 33-72), and is not intended to address any 
other related applications or claims. 
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combinations will operate and interact. It was thus deemed essential that some testmg be 
undertaken in an environment simulating the environment in which the reception system was 
intended to operate. 

However, a meaningful simulation of the intended use environment for the 
Prodigy Service could not be achieved in a conventional laboratory or test facility. User 
populations in the millions spread over a wide geographic area were considered necessary for a 
commercially viable service. Laboratory testing of even a very small fraction of such a 
population would have been physically and economically impossible to achieve at Prodigy's 
facilities, and of no use in determining the feasibility of the invention. 

To minimize the amount and duration of testing using members of the general 
public. Prodigy sought to advance the basic viability study of the reception system as far as 
possible in the first and second phases of testing, and leave expanded population; i.e., stress 
testing, to the end. The duration of the third phase of testing was the shortest of the test and 
development periods, lasting barely four months. 

The first phase of the test and development period extended from approximately 
January 1987 through September 1987. During that period, efforts were directed to establishing 
the viability of the general concepts underlying the proposed Prodigy Service. In this phase, 
testing was conducted confidentially by Prodigy employees and outside consultants either at the 
Prodigy facilities or from the homes of the Prodigy employees, the employees acting as pseudo- 
subscribers. (Minutes of Trintex Partners' Committee Meeting 11/18/87, p. 2 (Exhibit_L); 
Minutes of Trintex Partners' Committee Meeting 2/3/88, pp. 2-3 (Exhi bit2)X- 

Once Prodigy determined that the basic approach to the Prodigy Service was 
feasible, testing entered a second phase. In the second phase. Prodigy sought to determine if the 
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SenMce would continue to operate in the hands of users who, while experienced with computer 
technology, had not contributed to, nor participated in, the design of the Service. (Minutes of 
Trintex Executive Committee Meeting 4/6/88, pp. 2-3^(E xhibit 3 )L Additionally, Prodigy sought 
to determine if the reception system would continue to operate as changes were made in it to fix 
problems encountered and to encompass the broader range of subscriber hardware and operating 
system configurations that existed in the subscriber population Prodigy intended to serve. 
Prodigy further sought to test whether the reception system would continue to operate with the 
growing number of applications of increased complexity being added to the Service. Id. 

From its inception Applicants believed the Service would have to provide a broad 
range of transactional and informational applications to be accepted by the public. This was the 
genesis of Applicants' concept that storing less frequently changing data, i.e., constant data, on 
the user's PC and retrieving only frequently changing data, i.e., variable data, from the network 
would significantly enhance the speed of the Service. To be viable, it was also believed that the 
Prodigy Service would have to include transactional applications such as electronic banking, 
financial management, home grocery shopping, travel reservations and department store 
shopping, among others. Similarly, it would be essential to provide infomiational and 
entertainment applications such as current events, sports and business news. This range of 
applications required a broad scope of objects that varied in number and complexity. 
Accordingly, the objects for these applications presented a significantly varying level of load on 
the reception system and Service, which had to be tested before the Service could be 
commercially offered to the public. Well into the Fall of 1988, Prodigy was experimenting with 
ways to better facilitate transactional and informational applications by, e.g., reducing the 
amount of data that needed to be transmitted. (Memorandum from Robert Filepp, September 13, 
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1988 (Exhibit 4)). Further, since the range of applications called for a diversity of sponsorship 
and required a significant amount of software development, not all applications were initially 
immediately available for testing. Accordingly, reception system testing had to be coordinated 
in time with the expanding complexity of the Service, a coordination that extended through both 
the second and third phases of test and development. 

The second phase of testing and development extended from approximately the 
beginning of October 1987 through the end of March 1988. (Minutes of Trintex Partners' 
Committee Meeting 5/25/88, p. 2 (Exhibit^, During this phase, Prodigy organized three small 
groups of approximately 100 individuals each, the groups being located at select points across 
the United States corresponding in a small way to the extent of the communication links setup 
anticipated for the service (Hartford, CT; San Francisco, CA and Atlanta, GA). To foster interest 
and maintain confidentiality, individuals selected for each of the groups either had some relation 
to Prodigy or were likely to have technical interest and familiarity with computer technology that 
would enable them to test the reception system and Service. 

All testing in the second phase was conducted on a confidential basis and the 
reception system software and use of the service were provided to the users free of charge. Tight 
control was maintained over usage of the reception system and service by issuing identification 
numbers that the users had to present, and that had to be accepted, each time the user sought 
access to the service. Prodigy retained ownership of the reception system software, providing 
only a license for its use. In accordance with the terms of the license, the user was obliged not to 
attempt to reverse compile or otherwise reverse engineer the source code. Prodigy also 
monitored activity of these individuals by tracking identification numbers and noting frequency 
of use, type of applications viewed and duration of use sessions. Prodigy also maintained 



70I4V2 vl 



- 17 - 



PATENT ATTORNEY DOCKET NO. 1963-4727 

technical support telephone lines so users could report all problems encountered. In addition. 
Prodigy monitored the effect of usage on network performance. Prodigy also met periodically 
with representatives of the various groups to discuss the users' experiences and problems. And, 
as the reception system software was revised, the later versions were provided to the users for 
ftirther testing. (Minutes of Trintex Partners' Committee Meeting 2/3/88, p. 3 (Exhibit 2)). 

The first group in phase two that participated in the testing included 
approximately 100 IBM employees located in the Hartford, Connecticut area, since IBM was one 
of the founders of Prodigy. This group first became involved in October of 1987 when the 
Prodigy host and service were established for external access. In the course of the testing, the 
IBM-Hartford group remained substantially stable in size, the group growing only slightly from 
100 to 109 individuals over the 6 month period fi-om October 1987 through the end of the second 
phase of testing in March 1988. (Minutes of Prodigy Executive Committee Meeting, 6/29/88, 
attached Exhibit A (Exhibit 6)). 

The second group estabUshed in phase two of the test period included a panel of 
individuals from the Atlanta, Georgia and San Francisco, California areas. These individuals 
were typically employees of companies who were sponsoring or planning to sponsor applications 
on the Prodigy service, or who maintained some direct relationship with Prodigy, e.g., employees 
of the company that provided modems that were to be offered by Prodigy to future subscribers. 
This group began in approximately November of 1987 with some 30 individuals and grew to 163 
individuals by the end of the second phase of tesfing in March 1988. Id. 

Finally, the third group included members of the Conne cticut Com puter Society 
located in West Hartford, Connecticut, and comprised approximately 80 individuals in January 
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1988 when it first became active. Subsequently, the group expanded to 95 individuals by the end 
of the second phase of testing in March 1988. id. 

Hartford, Atlanta and San Francisco were always considered test cities during the 
testing and development of the Prodigy Service in 1987 and 1988. (Papes Declaration, H 5 
(Exhibit 7)). 

Prodigy issued "Rules for the Hartford Pilot," for the experimental run which took 

place between September 1987 and March 1988. The "Rules" detailed the confidentiality 

obligations imposed on the users and the expenmental nature of the testing as follows: 

During the Hartford Pilot of the PRODIGY service in which you 
are participating, each Member will play an important role in 
helping determine the future scope of the PRODIGY service. 
During the Pilot, TRINTEX will request your comments (to help 
refine the content) and your active on-line participation (to help 
test the system). It is important that each Member maintain the 
integrity and confidentiality of this important proprietary Pilot by 
not showing, discussing with or disclosing toany^-Member the 
PRODIGY service, the PRODIGY software, the'Service Guide, or 
other materials provided by TRINTEX as part of the Pilot, or their 
contents, and each Member agrees to abide by these requirements 
during and after termination of their Membership, and to return all 
materials toT^RINTEX upon request. j 

(Pp. 1-2 (Exhibit 8). The Rules also indicate that "[d]uring the Hartford Pilot, there will be no 

charge for use of the PRODIGY Service". (P. 2 , Exhibit 8) . 

At all times during the testing and development of the Prodigy Service, including 

during phase two of the testing, membership obligations and conditions were applied to all 
members on an equal basis. (Larson Declaration, ^ 7 (Exhibit 9) }, The "Rules for the Hartford 
Pilot" were indicative of the conditions under which users participated in the testing and 
development of the Prodigy Service during phases one and two, i.e., from September 1987 
through March 1988. Id,, *[\ 8. Users in the San Francisco, Atlanta and Connecticut Computer 
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Society panels would have been treated identically to the Hartford Pilot testers with regard to 
membership obligations and conditions. Id, T\\ 9-10. 

Following the second phase of test and development, these groups continued to 
operate into and through the third phase of test, growing only slightly in size. Ultimately, when 
Prodigy began to close out the third phase of testing in July 1988, the three groups comprised 
109 Hartford IBM employees, 166 Atlanta and San Francisco panel members and 96 Connecticut 
Computer Society members. (Minutes of Prodigy Executive Committee Meeting, 7/20/88, 
attached Exhibit A (E xhibit 10 ^ ) . 

As a result of technical problems encountered in the second phase of testing, the 
broadening range of PC hardware and operating system combinations required to be supported in 
the anticipated subscriber population, and the continuing increase in the number and complexity 
of Service applications, a new version of the reception system software was created during the 
second phase of testing. The new version was directed to improving, inter alia, response time 
and order processing, both of which were inextricably related to the claimed invention. 
Moreover, the system still had not been tested in an environment having a sufficiently large 
number of users, with minimal technical understanding as would show whether the Service could 
be offered generally to the public, or whether further changes would have to be made before the 
reception system and Service would perform as intended. (Minutes of Trintex Executive 
Committee Meeting 4/27/88, p. 3 (ExhiliiLU)). 

The Prodigy reception system was an integral part of a sophisticated computer 
network that was required to perfonn in harmony with the network system, application objects 
(e.g., data) and the user's PC to compose and display applications from objects stored locally on 
the user's PC or retrieved from the network if not stored locally. Because the demands of the 
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many reception systems were focused at the host computer, and because the Prodigy Service as 
structured was a pioneer system, it was by no means certain what the effect on perfomiance 
would be if the subscriber population was dramatically increased. (Papes Declaration, 1115 
(Exhibit 7)). 

It was therefore decided to test the reception system and Service over a broader 
user base, i.e., stress testing. It was proposed to gradually increase load levels by progressively 
adding groups of individuals secured from the public sector. This testing constituted the third 
phase of the test and development period which started on or about the beginning of April 1988 
and extended at least through the beginning of Au gust 198 8. (J.H. Beall, Monthly Activity 
Report August 1988, dated September 14, 1988, p.3 (Exhibit 12)). For the third phase. Prodigy 
added more users to the approximately 300 users of phase two; i.e., the users in the test groups in 
Hartford, Connecticut, Atlanta, Georgia and San Francisco, California. Distribution of the 
reception system software in the new version that emerged from the second phase of the test 
period began on or about March 29, 1988. Use by the "Founding Members" thereafter grew 
from approximately 50 members at the beginning of Apnl 1988, to 3,165 by the end of May 
1988. (Member Acquisition Thru July 25, 1988 (Exhibit 13); see also Minutes of Trintex 
Partners' Committee Meeting 5/25/88, p. 4 (Exhibit 5)). 

As before, in the phase three testing, the reception system software and Prodigy 
Service were provided free of charge. The "Founding Members" were a select group of 
individuals and groups representative of those who ultimately were likely to be interested in the 
Service. These test candidates were approached by mail and telephone and offered the reception 
system and Service on this limited test basis. As part of the program, tlie new users would 
receive revisions of the reception system software produced during phase two testing, along with 
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six months use of the Service for free. Additionally, if the participants wis^heiio_conta 
service at the endo f the six-mon th free period, they could do so 53 reduced rat e^that would 
extend for up to a year thereafter. Further, if the prospective new users did not have a modem to 
access the Service, Prodigy offered one at a reduced price. (Minutes of Trintex Partners' 
Committee Meeting 2/3/88, pp. 3-4 (Exhibit 2)). 

Prodigy retained owners hip of the rece ption system software during the phase 
three testing, providing only a Hcense to theFOspective users. Under the terms of the license, 
the users were precluded from any attempt to reverse compile or otherwise reverse engineer the 
source code. Prodigy again controlled use of the reception system software and access to the 
Service by issuing identification numbers that were required to be presented by the individual 
users at log on. Also as before. Prodigy compiled and maintained extensive records concerning 
the frequency, duration and character of use. A user telephone support line also was maintained 
for the reporting of problems. The consequence of the increased usage on all levels of the 
Service network was closely monitored. While the intemal operation of the reception system 
software was not disclosed to the new users, strict confidentiality was not imposed, since it was 
not practical in such a broad based test that was essential to detenmne whether the system would 
I work for Its intended purpose. (Papes Declaration, 116 (Exhibit 7)). In any event, the 
architecture with respect to the implementation of storage control was maintained as confidential 
information. 

At the beginning of June 1988, in accordance with the plan of gradual increase in 
system loading. Prodigy sought to broaden the user population to assure that when ultimately 
offered to the public. Service would operate as intended. Accordingly, at ihe beginning of June, 
Prodigy offered prospective users a further revision of the reception system and a free three 
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month period of use of the Service as so called "Charter Members." However, Prodigy did not 
offer continuation of the Service at a reduced rate following the free period. Additionally, while 
Prodigy later offered a modem at a reduced price, the price reduction was not as large as offered 
to the Founding Members. (Minutes of Trintex Partners' Committee Meeting 2/3/88, p. 3 
(Exhibit 2)). 

The Founding and Charter Member programs involved the acquisition of 
additional test users in the previously established test cities, i.e., Hartford, San Francisco and 
Atlanta, for the puqjose of testing the Service over a larger user base. (Papas Declaration, ^1 6 
(Exhibit 7); Larson Declaration, ^ 1 1 (Exhibit 9)). At the time of the Founding and Charter 
Member programs, the Prodigy Service was still in system test and it was felt that a significant 
expansion of the user base was needed to fully test the system functionality with a focus on 
identifying potential points of failures in the system. (Papes Declaration, 1 7 (Exhibit 7); Larson 
Declaration, 1|12 (Exhibit ^ 9)). The Founding and Charter programs were primarily directed to 
testing and development of the Prodigy Service and not to commercial marketing (Papes 
Declaration, 11 10 (Exhibit 7); Larson Declaration, 1 15 (Exhibit 9)). Mr. Theodore Papes, 
President and Chief Executive Officer of Trintex, later renamed Prodigy Services Company, 
made a videotape for Prodigy Employees in early 1989. (Papes Declaration, Yi 3, 12 (Exhibit 
7)). A copy of the videotape is attached as an exhibit to Mr. Papes' Declaration. The videotape 
was an effort to communicate the progress that had been made toward establishing the viability 
of the Prodigy Service. In the videotape, Mr. Papes referred to the Founding Member Program 
as "fine tuning" of the Service before it was made widely available. To the extent the meaning 
of the term "fine tuning" may be unclear, Mr. Papes has confinned that during the Spring and 
Summer of 1988, many technical issues remained to be resolved before the Prodigy Service 
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would be ready for marketing as a commercial service. Id^, 1111 13-14. Indeed, the first effort to 
commercially market the Prodigy Service did not occur until the expansion of the Service to 
several California Cities in the Fall of 1988. Id,, H 1 1; Larson Declaration, 1| 16 (Exhibit 9). 

In the phase three testing with Charter Members, like the other phases, Prodigy 
retained ownership of the reception system software, the new members receiving only a license 
to use it. And as before, in accordance with the terms of the license, the new users were obliged 
not to attempt to reverse compile or otherwise reverse engineer the source code. Prodigy again 
controlled use of the reception system software and access to the Service by issuing 
identification numbers that were required to be presented by the users at log on to the service. 
Extensive records concerning frequency, duration and character of use together with any 
problems were compiled. Prodigy also maintained a user support telephone line to enable the 
new users to report any problems. As before. Prodigy did not disclose the operation and 
structure of the reception system to the second group of users in the third phase of testing. 
These users were only given the reception system diskette and instructions on how to run the 
Service. Maintaining confidentiality was not practical in connection with use of the reception 
system or the Service during this phase. (Papes Declaration, H 16 (Exhibit 7)). In the third phase 
of test, from approximately June 1988, the number of users grew from approximately 3,165 
Founding Members to a total of approximately 8,330 Founding and Charter Members at the 
beginning of August 1988. (Member Acquisition Thru July 25, 1988 (Exhibit 13)). The 
following table shows the maximum number of users in each of the test groups during the 
different phases of testing. 
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Phase 1 


Phase 11 


Phase III 




Jan. -Sept., 1987 


Oct. 1987-March 1988 


April- August 1988 


Hartford Group 


0 


109 


110 


oiin rrdncisco 


n 
U 


loU 


165 


and Atlanta Groups 








Connecticut Computer 
Society 


0 


90 


100 


Founding Members 


0 


0 


3165 


Charter Member 


0 


0 


5165 


Total 

External Testers 


0 


359 


8705 



Under the circumstances, a total of 8700 testers was not a large group considering 



the objective of testing whether the Prodigy Service would work as intended on a large scale, i.e., 
with users numbering in the millions. Even after distribution to the Founding and Charter 
Members, the Prodigy Service had been distributed to a very small group of test users but had 
not yet been demonstrated to be capable of servicing a large number of users, (Papes 
Declaration, H 15 (Exhibit 7)). 

Following distribution of a revised version of the reception system software to the 
Charter Members in June of 1988, Prodigy recognized that another revision of the reception 
system would be required. However, Prodigy believed that if this further revision perfomied as 
intended, it could support release of the Service to the general public. Accordingly, following 
continued internal development of the further revision of the reception system, on or about 
August 5, 1988, Prodigy approved release of the further revised version of the software to 
support the public offering of the Service. Even then, testing of the system continued to focus on 
the shopping aspect of the Service as well as storage of data at the user's computer, both of 
which are aspects of claims 33-72: 
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In order to test throughout the entire service all jump words were 
accessed. Items were ordered from a variety of vendors, and mail 
was sent and allowed to accumulate. The size of STAGE.DAT 
was checked periodically throughout, and it did not change. 

(Testing of Prodigy Service, August 10, 1988 (Exhibit 14) ). The stage.dat file contained data 
that was not subject to frequent change or update and thus was retained on the user's computer 
between user sessions, i.e., constant data. A new version of the reception system software was 
released in August 1988 which was primarily directed to correcting a problem with remote 
updating of the stage file: 

Version 2.0 (Release 6.02.04D) was shipped to all enrolled 
members in August. In addition to many small features and 
usability enhancements, this release was intended to address the 
OMS 14 problem associated with the remote stage update. Since 
the distribution of Version 2.0 the OMS 14 problem has essentially 
disappeared- 

J,H. Beall, Monthly Activity Report August, 1988, dated September 14, 1988, P.3 (Exhibit 12). 
Further testing focused on the stage.dat file because there was a problem with that functionality, 
as evidenced by a "Problem Management Scoreboard" dated September 27, 1988: 



Stage and Cache.dat are corrupting the FAT tables and 
subsequently c: drives of members' pc's. This problem seems to 
have been interwoven with the stage.dat situation and may have 
become much less of a problem with V.6-2.4d. We Ye following 
primarily for tracking, at this point. 

(Membership Services - Problem Management Scoreboard, September 27, 1988, p-2 (Exhibit 
\5)X. The cache file contained data that was retained on a user's computer during a user session 
but was not retained between sessions, i.e., variable data. Problems with the stage.dat file were 
still being reported and monitored in October 1988: 



The problem is seen in the stage.dat file.... [I]t would appear that 
the stage files are not being updated, for whatever reason. 
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Membership Services- Problem Management Scorecard, October 12, 1988, p. 2 (Exhibit 16); S ee 
also Michael L. Gordon, Reception System Large Stage Support, October 20, 1988 ^Exhibit 17). 
Thus, even in late 1988, Prodigy could still not be certain that the system was functioning 
properly with respect to the claimed aspects of storing constant data at the user's computer and 

retrieving variable data from the network delivery system when needed. 

The concern over the speed of data delivery was still very much apparent in 

November 1988. as evidenced by the results of a "Satisfaction Survey" reported in Minutes of 

the Prodigy Executive Committee Meeting: 

[S]peed and lack of depth were the two most important negative 
things about the service, with speed being far ahead of any other 
item and having the largest difference between the mean 
importance and mean satisfaction scores. 

(Minutes of Prodigy Executive Committee Meeting, 1 1/22/88, p.2 (Exhibit 18)). Also in 
November 1988, it was very apparent that the software was still being modified to improve 
performance with respect to the storing of constant data on the user's computer. In a document 
titled "MS/DOS RELEASE 7.1 HIGHLIGHTS" dated November 9, 1988^(Exhibin9), a 
"VARIABLE SIZE STAGE" is listed as a perfomiance enhancement. This enhancement 
immediately follows the problem reported with the stage.dat file noted above. Still further, 
changes were being made with respect to the staging of data at the user's computer even as late 
as 1989. (Memorandum from C. Scrivanich et al. to J. Sacolick et al., January 23, 1 989^(Exhibi^ 
20) ("no STAGE.DAT file will exist on the Prodigy Installation Disks of release 8.N. A file 
called PAC_OBJ.DAT will take its' place. Install will create a STAGE.DAT customized to the. 
user's configuration and based on parameters contained in PAC_OB.I.DAT.")). This work on the 
staging of data was a direct result of feedback from user/testers of the system which indicated 
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that the staging of data at a user's computer could beneficially take advantage of the storage 
space available to optimize the delivery of data: 

Large stages may be beneficial in environments that can support 
the disk and memory resources necessary for their existence. 
Potentially, more objects can be locally available for use. There is 
concern that if the universe of stage candidate objects is increased 
to exploit the increased storage capacity of the large stages, there 
may be negative consequences to performance of the regular sized 
stage, such as thrashing. 

When a stage is created, it will be assigned the classification of 
either a regular or large sized stage. 

Two storage candidacy values will be created for objects which are 
candidates for a large stage, large stage candidate with and without 
version checking. An object with either candidacy will be a stage 
candidate for a large stage and will be treated as a cacheable object 
if a regular sized stage is present. 

Michael L. Gordon, Self Configuring Stage Description, Revised March 1989, pp. iii, 2-3 
(Exhibit2JjL{i^ above-quoted text was added in the March 1989 revision). 

Following approval in early August 1988, efforts went forward to distribute the 
final version of the reception system software to existing users, thus marking the end of the third 
phase of testing, Marketing of the Prodigy Service did not begin until late 1988. (Speech by 
Theodore C. Papes, Jr., November I, 1989 (Exhibit 22) ("Late last year, we began marketing 
PRODIGY in a handful of markets."); Papes Declaration, 111 (Exhibit 7); Larson Declaration, 
^116 (Exhibit 9)). 

Well into the Fall of 1988, users were being surveyed with regard to their views 
of the service to determine whether the service was performing its intended function as then 
configured. E^, Minutes of Prodigy Executive Committee Meeting, November 22, 1988 p.2 
(Exhibit 18) ("Mr. Polentz then reported on the results of a "Satisfaction Survey" conducted in 
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September among certain Founding and Charter members... speed and lack of depth were the 
two most important negative things about the service, with speed being far ahead of any other 
item"). 

During April 7-10, 1988, Prodigy representatives attended the West Coast 
Computer Faire in San Francisco, California at which they demonstrated the Prodigy service as it 
existed at the time. (Minutes of Trintex Executive Committee Meeting 4/27/88, p. 2 (Exhibit 
11)). The demonstration lacked a number of the transactional applications which were added 
later, such as at home banking, grocery shopping and travel reservations. For the 
demonstration. Prodigy used the version of the reception system soft^irejhat was thenjn^field^ 
tesTand that version was subsequently revised twice more during the third phase of the test and 
development period. The observers were told that while the Service was not yet generally 
available, it was expected to be provided in the San Francisco area by the Fall of 1988. Some of 
the transactional applications that were envisioned for the Service were described and a 
demonstration diskette distributed that displayed "screen shots" of certain segments of the 
Service without support of the network: This demonstration was similar to a slide presentation 
and was not a demonstration of the actual Prodigy Service. The observers were invited to fill 
out a follow-up card if they felt they wanted to be contacted when the service became publicly 
available in the San Francisco area in the fall. Approximately 4,000 cards were filled out and 
submitted. Id, attached Exhibit A. 

However, there was no attempt to sell the service or the reception^ystgm-software 
to any of the Computer Faire attendees. The purpose of the presentation at the faire was to 
assess the public reaction to the service as it then existed and the plans for its future 
development. For the Service to be successful it was thought necessary to include transactional 
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applications such as at home banking, stock brokerage, travel reservations and grocery shopping. 
However, those applications were as yet not available on the Service due to production 
complexity and associated difficulties. Accordingly, it was felt necessary to assess what the 
public reaction to the service would be with such applications missing, and whether the plan to 
provide such applications when the service was released would meet with public approval. 

Accordingly, the demonstration was not an attempt to commercially exploit the 
reception system. A limited number of terminals were used for the demonstration, each 
requiring only a prototype form of the reception system software. Because no major 
transactional applications were available at the time, the reception system was not called upon to 
exhibit certain features that were fundamental to its intended commercial form. Specifically, the 
reception system was not used to demonstrate its ability to operate with large user populations, or 
to show the full range of applications intended for the form of the Service envisioned for public 
release, or the range of PC hardware and operating system combinations it would be 
required to support when released. As noted, these were the features for which the reception 
system was still being tested for compliance and for which the reception system would be 
revised at least twice more before its release to support a general offering of the Service, As a 
result, the Computer Faire demonstration could not be considered an attempt to exploit the 
reception system, since the reception system was not yet in a commercially acceptable form 
suitable for sale. (Papes Declaration, ^\ 14 (Exhibit 7)). 

e. Documentary Evidence Of Experimental Use 

An abundance of documentary evidence of experimental use was presented above 
in Section Vl.d in the context of the description of the phases of testing of the Prodigy System. 
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As discussed above, the contemporaneous documentary evidence clearly demonstrates that the 
system was being tested, not marketed, prior to August 1988. 

f. Phases of Testing of Claim Elements 

The three phases of testing conducted up to about August 5, 1988 were directed to 
determining whether Applicants' technique for storing less frequently used data at the user's 
computer and accessing frequently changing data from the network delivery system as needed 
would work satisfactorily on a widely-dispersed user and geographic basis. This testing was at 
the heart of the invention as claimed in claims 33-72 as detailed in Section VLd above. 

g. Measures Taken To Ensure Confidentiality 

At no time in the course of Prodigy's test and development period was the 
Applicants' reception system in the public domain. The 1991 information disclosure statement 
expressly recites that all persons participating in the first testing phase of the Prodigy Service 
conducted between January 1987 and September 1987 maintained the project in confidence. In 
the first phase of test and development extending from January to September 1987, all activities 
concerning the reception system were confidential and handled exclusively by either Prodigy 
employees or outside consultants bound by express terms of confidentiality. Further, all 
documents and materials relating to the reception system were marked confidential and treated 
accordingly. As a result, the public had no access to or knowledge of the reception system 
during this phase of testing. Thus, the reception system was not in the public domain. There can 
be no issue of public knowledge or public use during the first phase of testing because the project 
was kept confidential. (Larson Declaration, Y\\ 7-10 (Exhibit 9)). 
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During the second phase of test and development; i.e., from the beginning of 
October 1987 to the end of March 1988, Prodigy continued to mark and maintain all documents 
and materials relating to the reception system as confidential Further, while the non-employee 
testers who participated in testing the reception system and Service dunng this phase, as 
described above, did receive prototype versions of the reception system software. Prodigy made 
no disclosure of the source code, or the structure or internal operation of the reception system to 
them. Rather, Prodigy provided the software to the non-employee test users on terms that 
required them not to attempt to reverse compile or otherwise reverse engineer the source code. 
Still further, the users were required to handle the reception system software and Service on a 
confidential basis. (Rules for the Hartford Pilot, pp. 1-2 (Exhibit 8)). Prodigy also made clear to 
entities providing applications to the service that all activities were considered of a testing nature 
and confidential: 

Welcome to the Pre-Launch pilot of the PRODIGY^^ Interactive 
Personal Service. 

As we discussed, the first PRODIGY Service Members who will 
see your application will be a controlled group of testers 

During the Pre-Launch Pilot, we must also ask you to maintain the 
confidentiality of the Pilot by not showing, discussing with nor 
disclosing to any non-Member the PRODIGY Service, the 
software diskettes. Service Guide, other materials provided to you 
as part of this Pre-Launch pilot, or their contents. By accepting 
this material, you agree to abide by these requirements- 
Letter from Jeannette McClennan to Gene Campbell, January 20, 1988 (Exhi^^ 

During all three phases of testing, feedback was sought and obtained from the test 
users to ascertain the problems with the system and how they might be resolved. In May 1988, 
a qualitative analysis of panel testing of the then-current version of the Service concluded: 
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The speed of response remains the dominant issue with regard to 
the mechanics of the service. Users are dissatisfied and frustrated 
by the length of time required for the subject to be called up and 
for information to be painted on the screen. They attribute the 
slowness of the service to the presence of general graphics. 

Qualitative Analysis: Panel Testing of the 6.0 version with April 1988 content. May 1988, P.7 
(E xhibit 24 ). In July 1988, a study of Founding Members concluded that " Speed is a, if not the, 
central problem with the Service today." (A Summary Report on Founding Member Focus 
Groups, July 1988, p.9 (Exhibit 25)). In this copy of the report, a handwritten interlineation 
reads "increase size of stage". Id^, p.9. Clearly, feedback from testers was being used to 
improve the system. Accordingly, there was no conduct by Prodigy in the second phase of the 
test and development period that could lead to the conclusion that the reception system software 
was in the public domain. (Larson Declaration, Y\\ 7-10 (Exhibit 9)). 

Finally, in the third phase of the test and development that extended from the 
beginning of April 1988 to the beginning of August 1988, Prodigy again continued to mark and 
maintain confidential all documents and materials that disclosed the source code, and the 
structure and internal operation of the reception system. While copies of the reception system 
software were distributed to the select groups of users secured in the third phase of testing, again. 
Prodigy made no disclosure of the reception system source code, its structure or internal 
operation. Rather, as in the second phase of test, Prodigy limited distribution of the reception 
system to distribution of diskettes on which the reception software was provided in object code 
only, a form substantially unintelligible to the user. Also, Prodigy retained ownership of the 
reception system software and merely licensed its use to these individuals. And, in accordance 
with the tenns of the license. Prodigy required the recipients to agree not to reverse compile or 
otherwise reverse engineer the reception system source code. Thus, Prodigy again took all 
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reasonable and usual steps under the circumstance to keep the structure and operation of the 
reception system secret, and put the public on notice that Prodigy had reserved Us right in the 
reception system. Accordingly, Prodigy engaged m no conduct in the third phase of the test and 
development period that could lead to the conclusion that the reception system software had been 
put in the public domain. (Papes Declaration Ti 5-16 (Exhibit 7); Larson Declaration Yi 1 1-16 
(Exhibit 9)). 

Regarding any issue of on-sale during the first through third phases of testing, the 
1991 Information Disclosure Statement expressly recites that the Prodigy Service was not the 
subject of a commercial sale prior to August 5, 1988. In addition, the investigation undertaken in 
response to the Office Action's inquiry has not found any evidence of a commercial sale of the 
claimed invention prior to no earlier than August 5, 1988. 

An abundance of evidence regarding measures taken to ensure confidentiality 
dunng the testing and development of the Prodigy Service during 1987 and 1988 is presented 
and discussed above in Section Vl.d. 

h. Implementation And Functionality of The 
System During Phase III of Testing 

The Prodigy reception system and Service were still undergoing testing, 
modification and development during phase three of the testing penod as detailed in Section Vl.d 
above. For example, problems were encountered with the staging of data, i.e., storing constant 
data on the user's computer, during this period and thereafter. 
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i. Founding Members Options for E xtended Service 

The so-called "Founding Members" (and Charter Members) options for extended 
services, detailed fully in Section Vl.d above, were an incidental aspect of the testing and 
development necessarily undertaken to determine whether the invention would work as intended 
over a broad user base. (Papes Declaration, 4-16 (Exhibit 7); Larson Declaration, 1 11-16 
(Exhibit 9)). This testing was essential given the pioneering character of the invention-the first 
broad-based public, multi-purpose, computer network. 

j Sponsor Agreements and Understanding with Di stributors 

Since Prodigy provided transactional as well as informational applications on its 
service, it was necessary during the test and development period to allow users to purchase goods 
and services offered in certain applications in order to determine if the transactional aspects of 
the service and the reception system would operate as intended. During phase two of the testing 
during the months of January, February and March of 1988, users purchased approximately $650 
worth of goods and services. In the four month period from April 1988 to the beginning of 
August of 1988, which constituted the third phase of testing, users purchased approximately 
S28,000 of goods and services. 

Significantly, the money paid for the goods and services purchased was paid to 
the sponsors of the applications that offered th e m, not to Pr odigy. Further, while these sponsors 
paid a fee to Prodigy to create and display the applications and advertisements that were run on 
the sponsor's behalf, these fees were paid to offset the cost of production, operating expense,/ 
testing and development costs. Prodigy realized no profit from these activities during the 
experimental period. 
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As is customary with software development. Prodigy held discussions with 
retailers who were to support retail sale of the reception system software when the software was 
to be offered to the general public m the Fall of 1988. By the beg.miing of February 1988, 
Prodigy had reached understandings with approximately six distributors in various channels of 
distribution; e.g., computer stores, software stores, specialty electronics stores and department 
stores, who indicated they would handle the software when it became available. In these 
discussions. Prodigy advised that the reception system and Service were under development, but 
were expected to become generally available between September and October of 1988. In 
addition, Prodigy expressly reserved the right not to supply the reception system software until 
Prodigy felt it was ready for release to the pubhc. By the end of April 1988, the number of 
distributors with whom Prodigy had reached such understandings had increased to approximately 
eight. (Minutes of Trintex Executive Committee Meeting 4/27/88, p. 2 (Exhibit 1 1)). 

Applicants respectfully submit that their invention was not ready to be 
commercially exploited until after the close of the test and development penods i.e., after August 
5, 1988. As noted above in connection with the description of the test period, at no time did 
Prodigy charge for the copies of the reception system software that were distributed or for access 
to and use of the Service. During the second and third phase of the test period, users paid for 
goods or services they purchased in the course of accessing certain of the transactional 
applications, the purchase prices for those items were paid to the sponsors of the applications that 
offered them. The payments were merely incidental to the testing of the reception system. Fees 
were also received from sponsors of applications that were running on, or in the process of being 
created to run on the service. However, those fees were paid for producing the applications and 
for maintaining them on the Service. The fees received for creating and maintaining the 
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appHcations on the Service were therefore wholly mcdental to the required testing of the 

reception system. 

The Federal Circuit has held payment in connection with experimental testing 
does not necessarily establish a section 102(b) bar but is merely one factor to be considered. 
P^.T.... Tnc v.GeoVannJnc, 828 F.2d 1558, 1564 (Fed. Cir. 1987). Moreover, where 
the payment is merely incidental to the expenmental testing, no bar will be found. For example, 
the Federal Circuit in TP Laboratories held that payment by dental patients for services rendered 
in futmg them w.th free, expenmental tooth positioning appliances that were the subject of the 
invention was incidental to the testing of the appliances, and neither destroyed the expenmental 
nature of the test, nor established a bar under 102(b). TPLatotone^ v. Pro Positioners. Ina , 
724 F.2d 965, 971-72 (Fed. Cir 1984). 

In the instant case, the sales and resulting payments were not compensation for 
use of Applicants' invention. Rather, they arose from the nature of the expenmentation. This is 
expressly the incidental benefit the Supreme Court approved in Ot^MEhzabeth, when it noted 
an invention could be experimentally "used in the premises of another and the use inure to the 
benefit of the owner" of the premises. Cit y of Elizabeth v. American Nicholson lavemenLCa, 
97 U.S. 126, 135 (1877); see also '^^.i-Pl^v Inc. v. Athletic Tr.rk ^ Court Constmction, 98 
F.3d 1318, 1322 (Fed. Cir. 1996). Accordingly, payments by the reception system users to 
application sponsors were only incidental to the testing and could not change the expenmental 
nature of Applicants' testing, or create a section 102(b) bar. 

As discussed above. Prodigy proposed to supply start-up kits for the service that 
would include reception system software in approximately the early fall when the reception 
system and Service was expected to be available for public distnbution. However, since the 
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reception system and Service were still in test and development stage, during the time of those 
discussions, Prodigy expressly reserved the right to withhold the kits and reception system 
software until it felt they were suitable for their intended purposes; i.e., at least until completion 
of the test and development period. 

As pointed out by the Federal Circuit, sales related arrangements in and of 
themselves do not establish a l62(b) bar especially where it has not yet been determined if the 
invention will operate acceptably in its intended environment. Shatterproof Glass Corp. v. 
T ihhe.v-Owens Ford Co. , 758 F.2d 613, 623 (Fed. Cir. 1985). At the time of discussions with the 
chain store retailers, testing was still in progress to ascertain whether the reception system would 
perform as intended; i.e., perform all of the functions of the reception system and continue to 
operate satisfactorily as the user population, application inventory and PC/operating system 
combinations were expanded. Such discussions thus could not have changed the experimental 
character of the test and development period or established a bar under section 102(b). 

k. August 5, 1988 Revised Version Release 

The revised version release of the Prodigy software that occurred in August 1988 
had been continually tested and modified with respect to aspects related to the claimed invention 
as discussed above. However, even if there were no differences from prior versions, there was 
no public use or on sale because the invention was being tested to determine whether it would 
work for its intended purpose until well after August 1988, as discussed above. 

\. Trintex References 

The references cited on form PTO-892 in the November 7, 2002 Office Action do 
not describe the detailed aspects of the invention and system as claimed in claims 33-72 and. in 
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any event, the Prodigy System was not fully operational in 1987 to the degree required to 
determine that the system would work to perform its intended function. 

VII. The Rejection of Claims 33-72 Under 35 U.S.C. $135(b) 

Applicants' Claims 33-72 have been rejected under 35 U.S.C. §135(b) as not 
being made prior to one year from the date on which Hill U.S. Patent No. 5,528,490 was granted. 
More specifically, the Office Action rejected Applicants' argument that the same subject matter 
of the Hill '490 patent Claim 1 was made by Applicants, in Claim I of their application Serial 
No. 08/158,026, filed November 23, 1993, from December 21, 1994 through April 1 1, 1996. As 
shown herein, amended Claim 1 of the grandparent of the present application, i.e., application 
Serial No. 08/158,026, filed Nov. 23, 1993 was for substantially the same subject matter as 
Claim 1 of the '490 patent. And because it was pending from December 21, 1994 through April 
11, 1996, amended Claim 1 of Applicants' grandparent application was made prior to one year 
from the date on which the Hill '490 patent was granted. Applicants are therefore entitled to 
present additional claims directed to the same subject matter as Hill's claims. MPEP §2307.02; 
Te/uka V. Wilson , 224 USPQ 1030, 1036 (Bd. Pat. Int. 1984). 

Amended Claim 1 of Applicants' grandparent application Serial No. 08/156,026 
was rejected under 35 U.S.C. § 103 in view of Johnson et al. during prosecution of Senal No. 
08/156,026. However, the standard that applies under 35 U.S.C. § 135(b) is not whether the 
claims are directed to the same or substantially the same patentable invention (the 35 U.S.C. 

^ ' " 

§ 135(a) standard for interference in fact), but rather whether they are directed to the same or 
substantially the same subject matter. See Bemian v.' Housey , 291 F3d 1345, 1351 (Fed. Cir. 
2002); In re Berger , 279 F.3d 975, 983 (Fed. Cir. 2002). Thus, whether the rejection of Claim 1 
as amended over Johnson et al. was a proper rejection is not relevant to the issue of whether 
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Claim 1 as amended was directed to the same or substantially the same subject matter as a claim 
of the Hill '490 patent. 

In any event, Applicants did not acquiesce to the rejection of amended Claim 1 
over Johnson et al. and expressly traversed the rejections in their grandparent application. ^ 
Applicants stand by that traversal and reiterate that amended Claim 1 is patentable over Johnson 
et al. as discussed above. A decision was made to forego prosecution of the claim as it existed to 
advance the case to issue. Applicants did not file a continuation application at that time to 
continue prosecution of amended Claim 1 as a matter of portfolio management, not because 
Claim 1 was unpatentable over Johnson et al. This in no way diminishes the fact that Applicants 
made a claim directed to the same or substantially the same subject matter within the time 
specified by 35 U.S.C.§ 135(b). 

Moreover, it "does not matter whether the claims are subsequently cancelled 
either before or after the issuance of the patent." Tezukav. Wilson, 224 USPQ at 1036. All that 
matters is that Applicants were claiming the required subject matter in some earlier application 
within one year of the issuance of the patent. Cragg v. Fogarty, 2001 WL 1339890, at *12 (Bd. 
App. & Int. 2001) ( citing, e.g. , Cnrhett v. Chisholm, 568 F.2d 759 (CCPA 1977) and lezuka). 
Applicants clearly met the applicable standard under 35 U.S.C. § 135(b). 

Copied Claim 33 reads as follows: 

33. A method for generating information related to a 
product, the method comprising the steps of: 

storing and maintaining variable data and constant data 
related to at least one product and a main revision status in 
a memory of a main computer, 

the main revision status indicating the revision level of the 
constant data stored in the main computer; 
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Storing constant data related to the at least one product and 
a remote revision status in a memory of a remote computer, 
the constant data being a subset of information data related 
to the at least one product, the remote revision status 
indicating the revision level of the constant data stored in 
the remote computer; 

transmitting the remote revision status from the remote 
computer to the main computer 

comparing the remote revision status with the main revision 
status; 

updating constant data stored in the memory of the remote 
computer with constant data maintained in the memory of 
the main computer that is different from the constant data 
stored in the memory of the remote computer; 

transmitting variable data related to the at least one product 
from the main computer to the remote computer; and 

integrating constant data related to the at least one product 
with the variable data related to the at least one product in 
the remote computer to generate the information data 
related to the at least one product including both constant 
data and variable data. 



Applicants' amended Claim 1 reads as follows: 

1. (amended) A method for operating a computer 
network so as to provide a multiplicity of users access to a 
multiplicity of applications, the applications each includmg 
data, 

the network having one or more host computers, a plurality 
of concentrator computers connected in groups of one or 
more to each of the host computers, and 

a plurality of reception system computers at which 
respective users may request applications, the reception 
system computers being connected in groups of one or 
more to each of the concentrator computers, the method 
comprising the steps of: 

a. estabHshing data stores at the host computers, the 
concentrator computers and the reception system 
computers; 
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b. distributing application data in accordance with a 
predetermined plan to data stores maintained, respectively, 
at the host computers, the concentrator computers and the 
reception system computers, 

the predetermined plan being implemented, at least in part, 
by ascribing a storage control attribute to the application 
data, the control attribute dictating eligibility of the 
application data for storage; and 

c. supplying application data to a respective reception 
system computer at which an application is requested so 
that the respective reception system computer can assemble 
the data which makes up the requested application by 
selectively collecting data from its own data store and the 
data stores of the respective host computer and concentrator 
computer to which it is connected. 

Copied Claim 33 is directed to storing and transmitting data between a user's 
computer and another computer remote from the user's computer via a modem type connection. 
Amended Claim 1 of Applicants' grandparent application is directed to applications containing 
data stored and transmitted in a computer network. 

Applicants' invention concerns a method for improving the performance of an 
interactive computer network to enable it to be used on an extremely wide-scale basis which had 
never before been accomplished. In accordance with Applicants' teaching, steps are described 
for reducing system response time to user information requests and for enabling inclusion of data 
rich content; as for example, graphics in the information provided. Moreover, by using 
distributed storage control as claimed. Prodigy was able to implement a much more cost 
effective network than would othenvise be possible in a system that did not use the remote 
computer's storage and computing resources. Utilizing the power of the PC was _at .the heart of 
the claimed invention. 
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Amended Claim 1 of Applicants' grandparent application is directed to 
distribution and updating of data in a network, with no restriction as to content/quantity of data 
or objects. As discussed above, the preferred embodiment of Applicants' invention as described 
in the specification is directed to distribution and updating of the data by using data objects. The 
following discussion makes reference to Applicants' disclosure of their preferred embodiment. 
The disclosure applies as well to distribution and updating of data without the use of data 
objects, i.e., a file-based system. The substantial similarity between Applicants' invention as 
presented in amended Claim 1 and copied Claim 33 becomes even more apparent upon 
companson of Applicants' amended Claim 1, as interpreted in light of Applicants' specification, 
with Claim 33. 

The Office Action argues that 35 U.S.C. § 1 35(b) was not satisfied because 
amended Claim 1 lacked material limitations found in Claim 33. However, this argument was 
incorrectly based on the absence of the exact same language in the copied claims and Applicants' 
amended Claim 1. As a matter of law, the Examiner is required to interpret amended Claim 1 by 
reference to Applicants' specification. In re Berger , 279 F. 3d at 983 ("the materiahty of a 
limitation in a claim copied to provoke an interference translates to the copying inventor's 
application for purposes of assessing compliance with 35 U.S.C. § 135(b)"); Tezuka, 224 USPQ 
at 1036 (where claim proffered as satisfying 35 U,S.C- §135(b) did not explicitly recite the 
amount of a compound recited by the copied claim, Board referred to the specification to 
interpret the claim); Coffman v. LjungkulK 205 USPQ 56, 62 (W,D. Ok. 1979) ("Even though 
there is a difference in scope between the claims timely asserted in the application and the count 
originated by copying a claim from the patent for interference pur|:)0ses, if the tenns employed in 
each case are merely different expressions for the same method or process achieving 
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substantially the same result, the requirement of the statute is met"); Stale^o v. Heymes , 263 
F.2d 334, 338 (CCPA 1959) (interpreting claim broadly enough to encompass different 
embodiments described in the specification of the copier's application and thus to exclude a 
limitation as material); Reiser v. Williams , 255 F.2d 419, 420 (CCPA 1958) (referring to the 
specification of the copier's application to interpret claim with respect to materiality of 
limitation); In re Schutte, 244 F.2d 323, 326 (CCPA 1957) ("The claims of the earlier 
/application, as we have indicated, are to be interpreted on the basis of a specification [prior 
application] which is substantially the same as that of the application at bar. While they are cast 
l^in a form quite different from claim 1 copied from Weinrich and use different terminology, it is 
clear to us that it is the same invention in substance that is being clamied."). 

Moreover, 35 U.S.C. § 135(b) is not to be strictly and harshly construed. A 
holding of noncompliance with the statute should be based only upon a substantial or critical 
failure of the applicant to assert claims to substantially the same subject matter prior to the one- 
year limitafion. Coffman , 205 USPQ at 61. When amended Claim 1 is interpreted by reference 
to Applicants' specification, as it must be, it is clear that Applicants were claiming the same 
subject matter as claimed by Hill in the '490 patent in satisfaction of 35 U.S.C. § 1 35(b). 

1. The Revision Status Limitation Of Copied 
Claim 33 Is Met By The Storage Control 
Attribute Of Applicants' Amended Claim 1 

The Claim 33 recitation of storing a constant data revision status at the mam 
computer is matched by Applicants' amended Claim 1 recitation of a "predetermined plan" and 
recitation of "the predetermined plan being implemented, at least in part, by ascribing a storage 
control attribute to the application data, the control attribute dictating eligibility of tlic 
application data for storage." 
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Applicants' specification clearly explains the meaning of predetermined plan with 

respect to the storage control attribute: 

The version value ... provides a parameter that can be ! 
checked against predetermined values available from 
delivery system 20 to determine whether an object [data] ; 
stored at RS 400 is sufficiently current to pemiit its j 
continued use, or whether the object has become stale and j 
needs to be replaced with a cuiTcnt object from delivery | 
system 20. ^ 

P. 135, lines 36 -p. 136, line 5. 

With respect to version checking for currency, where an 
object [data] stored at RS 400 is initially fetched or 
accessed during a session, a request to delivery system 20^ . 
is made for th^ ohiect bv spe cifving the version id of the J ^ 
oh iect stored at RS 400 . (emphasis added). ^ 

In response, delivery system 20 will advise the reception ; 
system 400 either that the version id of the stored object ' 
matches the currency value, i.e., the stored object is / 
acceptable, or deliver a current object that will replace the ;^ 
stored object shown to be stale. 



P. 139, lines 27-30. 

Applicants disclose that wherever data is stored, so too is its version identifier. 
For example, where data objects are used, as in the preferred embodiment, they are provided 
with a coded version identifier made up of the storage control byte and version control bytes 
which are elements of the object header. Specification, p. 135, lines 22-28. Since the object's 
version identifier is part of the object, the version control parameter related to an object is stored 
wherever the object is stored. Consequently, the latest version level of data contained in an 
object resides at the network delivery system (or main computer). P. 13, lines 1-10. When a file 
type fomial is used, version identification information is likewise included in the data file and 
thus accompanies the data wherever it is stored. 
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There is thus no material difference between storing a constant data revision 
status at the main computer as recited in Claim 33 and ascribing a storage control attribute as 
part of a predetermined plan as recited in Applicants' amended Claim 1. Applicants' 
specification shows that amended Claim 1 clearly encompasses storing a constant data revision 
status at the main computer. See In re Berger , 279 F.3d at 983, and the cases cited above 
requiring that claims put forth as satisfying 35 U.S.C. §135(b) must be construed by reference to 
their supporting specification. 

2. The Direction of Data Transmission 
Is The Same In Copied Claim 33 And 
Amended Claim 1 



The data travels in the same direction in Applicants' system as it does in the 
system described and claimed in the '490 patent. The fact that data may come from a 
concentrator computer in Applicants' system is irrelevant. The concentrator computer is part of 
Applicants' network delivery system and as such is part of a system that performs the same 
function as the main computer of the '490 patent. Moreover, the concentrator computer is not a 
matenal limitation of Applicants' amended Claim 1. See InreBerger , 279 F.3d at 983. 

3. The Steps Of Comparing The Remote Revision Status 
With The Main Revision Status and Updating The 
Constant Data At The Remote Computer Is The Same 
In Copied Claim 33 And Applicants' A mended Claim 1 

The Claim 33 step of comparing the version of the constant data stored in the 
memory of the remote computer with the version of the same data stored in the memory of the 
main computer (i.e., network delivery system) is matched by the corresponding recitation of 
amended Claim 1 of "distributing application data in accordance with a predetermined plan to 
data stores maintained, respectively, at the host computers, the concentrator computers and the 
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reception system computers" includes, mter alia, selective updating of stale data based on 
version checking. Applicants' disclosure supports this claim language as encompassing the same 
subject matter as the revision status checking recitation of copied Claim 33. Applicants' 

specification states in this regard: 

In preferred form, the method aspect of the invention 
includes ... steps for distributing selected objects [data] 
within the network in accordance with a predetermined 
plan based on the likelihood a us er will request a particular 
a pplication , (emphasis added). 



P. 5, hnes 1-7. 

[T]he method aspect of operating the preferred form of the 
network apparatus includes steps for establishing data 
stores ... and, thereafter, distributing apphcation data to 
data stores ... in accordance with a predetermined plan 
designed to reduce the time re quired to present a requested 
a pplication , (emphasis added). 



P. 5, lines 20-27. 

[T]o render a public informational and transactional 
network of the type considered here attractive, the network 
must be both economical to use and fast. That is to say the 
network must supply infonnation and transactional support 
to the user at minimal costs and with a minimal response 
time. In accordance with the present invention, these 
objectives are sought to be achieved by locating as many 
information and transactional support objects which the 
user is likely to request, as close to the user as possible, i.e., 
primarily at the user's RS 400 and secondarily at delivery 
system 20. In this way, the user will be able to access 
objects [data] required to support a desired application with 
minimal intervention of delivery system 20, thus reducing 
the cost of the session and speeding the response time. 



p. 134, line 29 - p. 135, line 5. 



Additionally, to assure currency of the infonnation and 
transaction support provided at RS 400, objects [data] are 
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further coded for version identification and checking in 
accordance with a system of priorities that are reflected in 
the storage candidacy coding. 

P. 135, lines 17-21. Thus, the recitation of a predetermined plan of information distribution 
constitutes, inter alia, version identification and checking so that stale information is not used. 

Applicants describe different categories of data depending on its frequency of 
change. RAM and disk cached objects are retained at most for the duration of user sessions (and 
thus are "variable data"), while objects stored in the stage file are retained between sessions (and 
thus are "constant data"). The storage control field, located in the header portion of an object, 
i.e., "storage candidacy", indicates whether the object is stageable, cacheable or trashable: 

Storage objects [i.e., CONSTANT DATA] must not be 
subject to frequent change or update. They are retained 
between user sessions on the system... Cacheable objects 
[i.e., VARIABLE DATA] can be retained during the 
current user session, but cannot be retained between 
sessions. These objects usually have a moderate update 
frequency... Trashable objects [another example of an even 
more transient type of VARIABLE DATA] can be retained 
only while the user is in the context of the partitioned 
application in which the object was requested. Trashable 
objects usually have a very high update frequency and must 
not be retained to ensure that the user has access to the 
most current data... Specifically, to effect object storage 
management, objects are provided with a coded version id 
made up of the storage control byte and version control 
bytes identified above as elements of the object header. . . 

P. 134, line 2- p. 135, line 25. An object storage facility provided in the RS software manages 
objects remotely stored in a local store including a cache (segmented between available RAM 
and fixed size disk file) and stage (fixed size disk file). P. 133, line 30-p 134, line 28. 

Applicants' specification further states with regard to version checking to. 
maintain currency of remotely stored information: 
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When objects [data] are requested from object storage 
facility 439, only the latest version of the object will be 
provided to guarantee currency of information to the user. 
Oh ject storage facilitv 439 a'^sures currency by requesting 
version verification from network 10 for those objects 
which are available locally and by r equesting obiects which 
are not locally available fr om delivery system 20 where 
currency is maintained, (emphasis added). 



P. 133, lines 7-13. 



The version value ... provides a parameter that can be 
checked against predetermined values available from 
delivery system 20 to determine whether an object [data] 
stored at RS 400 is sufficiently current to permit its 
contmued use, or whether the object has become stale and 
needs to be replaced with a current object from delivery 
system 20. 



P. 135, lines 36 - p. 136, line 5. 

With respect to version checking for currency, where an 
object [data] stored at RS 400 is initially fetched or 
accessed during a session, a request to delivery system 20 
is made for the object by specifying the version i d of the 
obiect stored at RS 400 . (emphasis added). 

In response, delivery system 20 will advise the reception 
system 400 either that the version id of the stored object 
matches the currency value, i.e., the stored object is 
acceptable, or deliver a current object that will replace the 
stored object shown to be stale. 

P. 139, lines 27-30. Applicants' predetermined plan thus clearly includes comparing the remote 
revision status with the main revision status stored at the main computer. Thus, amended Claim 
I of Applicant's grandparent application is directed to selective transmission of data to maintain 
currency of constant data stored at the remote computer, which is the same as transmitting and 
comparing a remote revision status with a main revision status as recited by copied Claim 33. 
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Applicants' recitations in amended Claim 1 of supplying application data to a 
reception system and of assembling data at the reception system from data collected from the 
network further correspond to limitations found in copied Clami 33. 

Applicants' specification explains that after transmitting the remote revision 
status to the network delivery system and comparing it to the main revision status, stale constant 
data is updated at the remote computer: 

[D]elivery system 20 will ... deliver a current object [data] 
that will replace the stored object shown to be stale. 

P. 139, lines 27-30. Applicants' recitation of "distributing application data in accordance with a 
predetermined plan. . ." thus clearly includes updating constant data at the remote computer. 

Applicants' recitations of supplying application data to a reception system, 
assembling data at the reception system from data collected from the reception system and 
assembling data at the reception system from data collected from the network further correspond 
to the "updating" limitation of copied Claim 33. 

Applicants' specification clearly shows that amended Claim 1 encompasses 
comparing the remote revision status with the main revision status and updating the constant data 
at the remote computer. See In re Berger , 279 F.3d at 983, and the cases cited above requiring 
that claims put forth as satisfying 35 U.S.C. §135(b) must be construed by reference to their 
supporting specification. 

4. The Step Of Combining Constant And Variable 
Data At The Remote Computer Is The Same In 
Copied Claim 33 And Amended Claim 1 

Claim 33 recites the step of collecting and combining the constant data stored at 
the remote computer with variable data that is transmitted from the network computer to provide 
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the requested information about the product or sewice to the user of the remote computer. 
Applicants' disclosure supports the corresponding amended Claim 1 recitation of "supplymg 
application data to a respective reception system computer at which an application is requested 
so that the respective reception system computer can assemble the data which makes up the 
requested application by selectively collecting data from its own data store and the data stores of 
the respective host computer and concentrator computer to which it is connected" as constituting 
the boUecting and combimng of constant and variable data to provide information to a user at the 
remote computer. 

Applicants give the example of a user at the remote computer purchasing an apple 
through the network. The price of an apple is transmitted from the network because it is data 
that changes so frequently that there is no point in storing it at the RS (and thus corresponds to 
VARIABLE DATA). P. 137, lines 13-19. At p. 148, line 26 - p. 153, line 10, the entire 
procedure by which the user interacts with the RS and the network to purchase apples is detailed. 
Again, at p. 149, line 36, the price of an apple is obtained from the network delivery system (or 
mam computer) after being selected from the RS. The presentation data etc. related to the 
interactive apple purchase corresponds to the CONSTANT DATA of Claim 33 which is stored at 
the RS because it does not change frequently. The constant presentation data, etc. related to the 
purchase of apples is cleariy shown in Applicants' Fig. 3b, with blank spaces for the variable 
pnce data transmitted from the network. Thus, Applicants disclose, inter alia, integrating 
constant data related to an apple purchase stored at an RS with variable data related to, e.g., the 
price of an apple obtained from the network. This disclosure governs the interpretation of 
amended Claim 1 as encompassing the collecting and combining of constant and variable data to 
provide infoniiation to a user at the remote computer. See In re Berger , 279 F.3d at 983, and the 
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cases cited above requiring that claims put forth as satisfying 35 U.S.C. §135(b) must be 
construed by reference to their supporting specification. 

5. The Step Of Distributing Variable Data From The Main 
Computer To The Remote Computer Is The Same In 
Copied Claim 33 And App licants' Amended Claim 1 

The step of transmitting variable data from the main computer to the remote 
computer in Claim 33 corresponds to Applicants' amended Claim 1 recitation of "supplying 
application data to a respective reception system computer at which an application is requested 
so that the respective reception system computer can assemble the data which makes up the 
requested application by selectively collecting data from its own data store and the data stores of 
the respective host computer and concentrator computer to which it is connected". 

Applicants describe different categones of data depending on its frequency of 
change. RAM and disk cached objects are retained at most for the duration of user sessions (and 
thus are "variable data"), while objects stored in the stage file are retained between sessions (and 
thus are "constant data"). The storage control field, located in the header portion of an object, 
i.e., "storage candidacy", indicates whether the object is stageable, cacheable or trashable: 

Storage objects [i.e., CONSTANT DATA] must not be 
subject to frequent change or update. They are retained 
between user sessions on the system... Cacheable objects 
[i.e., VARIABLE DATA] can be retained during the 
current user session, but cannot be retained between 
sessions. These objects usually have a moderate update 
frequency... Trashable objects [another example of an even 
more transient type of VARIABLE DATA] can be retained 
only while the user is in the context of the partitioned 
application in which the object was requested. Trashable 
objects usually have a very high update frequency and must 
not be retained to ensure that the user has access to the 
most current data... Specifically, to effect object storage 
management, objects are provided with a coded version id 
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made up of the storage control byte and version control 
bytes identified above as elements of the object header.,. 

P. 134, lines 2- p. 135, line 25. An object storage facility provided in the RS software manages 
objects remotely stored in a local store including a cache (segmented between available RAM 
and fixed size disk file) and stage (fixed size disk file). P. 133, line 30-p 134, line 28. 

Applicants' specification explains that data which changes frequently does not 
persist on the remote computer beyond, at most, a particular user session, but rather is retrieved 
from the main computer (i.e., the network delivery system) when needed: 

A first candidacy value is applied where the object [data] is 
very sensitive to time; e.g., news items, volatile pricing 
information such as might apply to stock quotes, etc. In 
accordance with this first value, the object will not be 
permitted to be stored on RS 400, and RS 400 will have to 
request such objects from delivery system 20 each time it is 
accessed, thus, assuring currency. A second value is 
applied where the object is sensitive to time but less so than 
the first case; e.g., the price of apples in a grocery shopping 
application. Here, while the price might change from day 
to day it is unlikely to change during a session. 
Accordingly, the object will be permitted to persist in RAM 
or at the disk cache during a session, but will not be 
permitted to be maintained at RS 400 between sessions. 

Filepp et al., p. 137, lines 8-19. When properly constructed by reference to the supporting 
specification, amended Claim 1 clearly includes the transmission of variable data from the main 
computer to the remote computer. See In re Berber , 279 F.3d at 983, and the cases cited above 
governing the interpretation of claims for purpose of 35 U.S.C. § 135(b). 

6. The Data Types Are The Same In Copied Claim 
33 And Applicants' Amended Claim 1 

Claim 33's recitation of storing variable and constant data at the main computer 
corresponds to Applicants' recitation in amended Claim 1 of "distributing application data in 
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accordance with a predetermined plan to data stores maintained, respectively, at the host 
computers, the concentrator computers, and the reception system computers". Applicants' 
disclosure supports amended Claim I's language regarding the distnbution of application data 
within the network as constituting the same subject matter as the storing of constant and vanable 
data on a main computer, as recited in Claim 33. As can be seen from the specification. 
Applicants' network delivery system transmits data to a requesting RS, and routes data entered 
by the user or collected at the RS within the network. P. 13, lines 1-10. Applicants' amended 
Claim 1 recitations of a network and establishing data stores at the various computers in the 
network, respectively, further correspond to the recitation in Claim 33 of storing variable and 
constant data at the main computer. 

Applicants disclosure is far more robust than Hill's and, at the very least, 
describes different categories of data depending on its frequency of change. RAM and disk 
cached objects are retained at most for the duration of user sessions (and thus are "variable 
data"), while objects stored in the stage file are retained between sessions (and thus are "constant 
data"). As discussed above, the storage control field indicates whether the object is stageable, 
cacheable or trashable. P. 134, lines 2- p. 135, line 25. An object storage facility provided in the 
RS software manages objects remotely stored in a local store including a cache (segmented 
between available RAM and fixed size disk file) and stage (fixed size disk file). P. 133, line 30- 
p 134, line 28. 

As for specific examples of constant and variable data. Applicants disclose, at p. 
137, line 6 - p. 138, line 26 of their specification, that data has a storage candidacy value which 
dictates whether and for liow long the data is stored at llic RS. Two of the disclosed storage 
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candidacy values (the first and second values) con-espond to the variable data recitation of Claim 
33 in that they indicate different degrees of variable data: 

A first candidacy value is applied where the object [data] is 
very sensitive to time; e.g., news items, volatile pricing 
information such as might apply to stock quotes, etc. In 
accordance with this first value, the object will not be 
permitted to be stored on RS 400, and RS 400 will have to 
request such objects from delivery system 20 each time it is 
accessed, thus, assuring currency. A second value is 
applied where the object is sensitive to time but less so than 
the first case; e.g., the price of apples in a grocery shopping 
application. Here, while the price might change fi-om day 
to day, it is unlikely to change during a session. 
Accordingly the object will be permitted to persist in RAM 
or at the disk cache dunng a session but will not be 
permitted to be maintained at RS 400 between sessions. 

P. 137, lines 8-19. Other (the third and fifth) values corresponds to the constant data of Claim 
33: 

[W]here the object [data] concerns information sufficiently 
stable to be maintained between sessions a third storage 
candidacy value is set to permit the object to be stored at 
RS 400 between sessions, on condition that the object will 
be version check[ed] the first time it is accessed in a 
subsequent session. 

P. 137, lines 20-25. 

Where the object [data] is of a type required to be stored at 
RS 400, as for example, objects needed to support standard 
screens, it is coded for storage between sessions ... 
However, where such objects are likely to change in the 
future they may be required to be version checked the first 
fime they are accessed in a session and thus [are] given a 
fifth storage candidacy value. 

P. 138. lines 1-7. Variable data, therefore, does not persist at the remote computer. U is 
retrieved from the network delivery system (or "main" computer) at which it is stored. Constant 
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data, as noted above, is stored on the RS but is version checked when accessed. Thus, as noted, 
the most current constant data is always available from the network delivery system (or main 
computer). 

The recitation in Claim 33 of storing the requested constant data at the remote 
computer is further matched by Applicants' amended Claim 1 recitation of "distributing 
application data in accordance with a predetermined plan to data stores maintained, respectively, 
at the host computers, the concentrator computers and the reception system computers." 
(including supplying data to the RS). Applicants' disclosure supports the amended Claim 1 
language regarding distributing application data within the network as constituting the same 
subject matter as Claim 33 recitation of storing constant data at the remote computer. As can be 
seen from the specification, Applicants' network delivery system transmits data to a requesting 
RS, and routes data entered by the user or collected at the RS within the network. P. 13, lines 1- 
10. 

Applicants' amended Claim 1 recitations of reception system computers at which 
applications are requested and establishing data stores at various locations within the network, 
respectively, further conespond to storing constant data at the remote computer as recited ni 
Claim 33. 

The recitation in Claim 33 of stonng a constant data revision status at the remote 
computer is matched by Applicants' amended Claim 1 recitation of a "predetemiined plan" and 
recitation of "the predetermined plan being implemented, at least in part, by ascribing a storage 
control attribute to the application data, the control attribute dictating eligibility of the 
application data for storage". 
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As indicated above, m Applicants' disclosure data assigned the third or fifth 
storage candidacy value are examples of constant data. Applicants specification discloses that, 
in the preferred embodiment, "objects carry application program instructions and/or information 
for display at [the] monitor screen... of [the] RS." P. 9, lines 29-30. In this embodiment, the RS 
includes means for selectively storing program instructions and display data in the form of data 
objects which are stored at the RS in accordance with a predetermined storage criteria. P. 10, 
lines 13-27. Applicants further disclose that "to effect object storage management, objects are 
provided with a coded version id made up of the storage control byte and version control bytes" 
which are "elements of the object header." P. 135, lines 22-28. The currency of data stored at 
the RS is established by virtue of the storage control parameters and a check of the version level 
prior to use. P. 10, lines 13-19. Version checking is performed in the same way for data files, 
i.e., the version level is included in the file containing the data and the version checking is 
performed in the same way. 

Applicants' amended Claim I recitation corresponding to the Claim 33 step of 
transmitting the remote revision status from the remote computer to the main computer is the 
step of "distributing application data in accordance with a predetermined plan to data stores 
maintained, respectively, at the host computers, the concentrator computers and the reception 
system computers" includes, inter alia, selective updating of stale data based on version 
checking. Applicants' disclosure supports this claim language as encompassing the same subject 
matter as the Claim 33 revision status checking recitation. As discussed immediately above, the 
currency of data stored at the RS is established by virtue of the storage control parameters and a 
check of the version level prior to use. Applicants' specification states in this regard: 
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In preferred form, the method aspect of the invention 
includes ... steps for distributing selected objects [data] 
within the network in accordance with a predetermined 
plan based on the Ukelihood a user will request a particular 
a pplication , (emphasis added). 



[T]he method aspect of operating the preferred form of the 
network apparatus includes steps for establishing data 
stores ... and, thereafter, distributing application data to 
data stores ... in accordance with a predetermined plan 
designed to reduce the time required to present a requested 
a pplication , (emphasis added). 



P. 5, lines 20-27. 

[T]o render a public infomiational and transactional 
network of the type considered here attractive, the network 
must be both economical to use and fast. That is to say the 
network must supply information and transactional support 
to the user at minimal costs and with a minimal response 
time. In accordance with the present invention, these 
objectives are sought to be achieved by locating as many 
information and transactional support objects [data] which 
the user is likely to request, as close to the user as possible, 
i.e., primarily at the user's RS 400 and secondarily at 
delivery system 20. In this way, the user will be able to 
access objects [data] required to support a desired 
application with minimal intervention of delivery system 
20, thus reducing the cost of the session and speeding the 
response time. 

P. 134, line 29 -p. 135, line 5. 

Additionally, to assure currency of the information and 
transaction support provided at RS 400, objects [data] are 
further coded for version identification and checking in 
accordance with a system of priorities that are reflected in 
the storage candidacy coding. 
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p. 135, lines 17-21. Thus, the recitation of a predetermined plan of information distribution 
constitutes, inter aha, version identification and checking so that stale information is not used. 
Applicants' specification further state with regard to version checking to maintain currency of 

remotely stored information: 

When objects [data] are requested fi-om object storage 
facility 439, only the latest version of the object will be 
provided to guarantee currency of information to the user. 
Object storage facility 439 assures currency by requesting 
version verification from network 10 for those objects 
which are available locally and by requesting objects which 
are not locally available from delivery system 20 where 
currency is maintained. 



P. 133, lines 7-13. 

The version value ... provides a parameter that can be 
checked against predetermined values available from 
delivery system 20 to determine whether an object [data] 
stored at RS 400 is sufficiently current to permit its 
continued use, or whether the object has become stale and 
needs to be replaced with a current object from delivery 
system 20. 



P. 135, lines 36 -p. 136, line 5. 

With respect to version checking for currency, where an 
object [data] stored at RS 400 is initially fetched or 
accessed during a session, a request to delivery system 20 
i<; made for the o b ject bv soec ifvine the version id of the 
obiect stored at RS 400 . (emphasis added). 

In response, delivery system 20 will advise the reception 
system 400 either that the version id of the stored object 
matches the currency value, i.e., the stored object is 
acceptable, or deliver a current object that will replace the 
stored object shown to be stale. 

P. 1 39, lines 27-30. Applicants' prcdetemiined plan of data distribution thus clearly includes 
transmitting the remote version status from the remote computer to the main computer as recited 
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in 



Claim 33. Thus, amended Claim 1 of Applicants' grandparent application is directed to 
selective transmission of data to maintain currency of constant data stored at the remote 
computer, which is the same as transmitting and comparing a remote revision status with a main 
revision status as recited by copied Claim 33. 

When properly constmed by reference to Applicants' supporting specification, 
amended Claim I clearly includes all of the material limitation of copied Claim 33. See hue 
Berger, 279 F.3d at 983, and the cases cited above governing the interpretation of claims for 
purposesof35U.S.C.§ 135(b). 

7. Applicants' Amended Claim 1 Inherently 
Includes The Same Order of Steps As 
Copied Claim 33 . 

A copied claim is entitled to the earlier effective filing data of an applicant's prior 

existing claim if all material limitations of the copied claim are present in, or necessarily result 

from, the limitations of the prior claim. Corbett , 568 F.2d at 766; In re Schutte , 244 F.2d at 326; 

Stalego, 263 F.2d at 339 ("For the reasons given above, we are of the opinion that count 2 and 

Heymes et al. claim I are directed to substantially the same invention, since they relate to 

substantially identical processes designed to produce the same result and differ only in mmor 

details which do not materially affect the result obtained.") The sequence of steps is self-evident 

and inherent in the predetermined plan of data distribution of amended Claim 1. 

VIII. The Examiner's Statement Regarding The Rejection of Applicant's 
Amended Claim 1 Has No Bearing On T he Present Case 

The Office Action at page 29 relies on the rejection of Claim l. of. Serial No... 

08/158,026 as unpatentable over Johnson et al. as supporting a rejection under 35 U.S.C 

§ 135(b). According to the Office Action, Applicants' amended Claim 1 and Applicants' copied 
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Claims "are not the same invention and [therefore] the copied claims were not made prior to one 
year from the date Hill '490 issued" In making this rejection, the Office action improperly 
confuses the standard applicable to a rejection under 35 U.S.C. § 135(b) with the standard 
applicable to an interference-in-fact determination under 35 U.S.C. § 135(a). 

Under 35 U.S.C. § 135(a) the test for interference-in-fact is whether the claims of 
two or more parties are directed to the same or substantially the same patentable invention. In 
contrast, under 35 U.S.C. § 135(b), the test is whether applicant made a claim directed to the 
same or substantially the same subject matter of a patent claim prior to one year from the date the 
patent issued, not whether they are directed to the same mvention. Thus, the rejection of Claim 1 
of application Serial No. 08/158,026 as being unpatentable over Johnson et al. is not a proper 
basis for a rejection of copied Claim 33 under 35 U.S.C. § 135(b). 

In any event, as discussed previously herein, Johnson et al., do not teach or 
suggest the. classification of data into types depending on the frequency of change of the data, 
i.e., constant and variable data, ascnbing storage control attnbutes to the data depending on its 
frequency of change and updating constant data at the remote computer if it is determined to be 
stale after comparing the revision status of analogous data stored on the main computer. Johnson 
et al. describe file sharing between nodes in a distributed computing environment and say 
nothing about the constant/variable dichotomy with respect to product infomiation displayed on 
a remote computer in a network as appreciated, disclosed and claimed by Applicants. 

The Office Action's speculation about IBM's patent prosecution practices does 
not constitute a substantive basis for rejection. As discussed above, a decision was made to 
forego prosecution of amended Claim 1 as a portfolio management issue. Such decisions are 
made every day by every large patent owner and are not necessarily indicative of anything with 
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respect to the patentability of claims, as the Office Action improperly suggests. For these 
reasons. Applicants respectfully submit that they did properly make a claim to the same subject 
matter of the issued Hill '490 patent prior to one year from the date on which Hill '490 was 
granted. 

IX. The Rejection of Applicants Claims 62-7 2 Is Unfounded 

A method claim constitutes the same subject matter as an apparatus claim if the 
subject matter as a whole is indistinguishable: 

Though a claim expressed in "means for" (functional) 
terms is said to be an apparatus claim, the subject matter as 
a whole of that claim may be indistinguishable from that of 
a method claim drawn to the same steps performed by the 
means. 

Tn re Freeman , 573 F.2d 1237, 1247 (CCPA 1978). Applicants assert that this is the case here 
and that the same material limitations appear in the respective method and apparatus claims. 

X. The Office Action's Comments As To Applicants' Remarks 

Applicants' amended Claim 1 recites, inter alia, "distributing application data in 
accordance with a predetemiined plan... by ascribing a storage control attribute to the 
application data" and "supplying application data to a respective reception system computer at 
which an application is requested so that the respective reception system computer at which an 
application is requested can assemble the data which makes up the requested application by 
selectively collecting data from its own data store and the data stores of the respective host 
computer and concentrator computer to which it is connected". The subject matter of amended 
Claim 1 is substantially the same as copied Claim 33, as is clear when amended Claim 1 is 
construed by reference to Applicants' specification, as it must be as a matter of law, as explained 
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above. The order of steps in amended Claim 1 is inherently the same as the steps of copied 
Claim 33. There is only one sequence in which to perform the steps and achieve the result 
sought to be achieved by both copied Claim 33 and amended Claim 1. No other sequence of 
steps makes practical sense. The Office Action's remarks are thus unfounded. 



CONCLUSION 

Applicants' Claims 33-72, respectively, define the same subject matter as the Hill 



'490 patent Claims 1-40. In addition, Applicants' amended Claim 1 of their grandparent 
application also is directed to the same subject matter as the Hill '490 patent Claim 1. For the 
reasons set forth above, the rejection of Claims 33-72 under 35 U.S.C. § 135(b) in view of the 
Hill '490 patent should be withdrawn and Claims 33-72 should be allowed. An interference 
should be declared using the Count proposed in Applicants' September 18, 1997 Request for 
Interference, i.e.. Claim 33 of the present application. The undersigned attorney for Applicants 
stands ready to meet with the Examiner either in person or telephonically to discuss any matters 
discussed herein if the Examiner feels that a meeting would assist their consideration of the 
Applicants' request. No additional fee is required for the Response herein. 

May 5, 2003 Respectfully submitted, 



MORGAN & FINNEGAN, L.L.P. 
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New York, New York 10154-0053 
(212) 758-4800 
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Registration No. 26,710 
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